home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 349 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.6 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Throwing an exception from within a signal handler
  5. Date: 09 Feb 1996 15:33:18 PST
  6. Organization: University of California, Riverside Department of Computer Science
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4fggbj$hsd@galaxy.ucr.edu>
  9. References: <4f2th6$4qh@galaxy.ucr.edu> <DMH620.FKn@falcon.daytonoh.attgis.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 9 Feb 1996 22:03:31 GMT
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMRvcZUy4NqrwXLNJAQHylgH/c+cy7tnyULBlYthmVFK25zDIT/6UPZAN
  15.     66UtB2Rz+j4DIti/3EzvZgo+OzqO2zQ3cgZlc/QrOUXp6wor/azspg==
  16.     =RUPA
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
  20. : > ==========Tom Payne, 2/4/96==========
  21. : [...]
  22. :  
  23. : > Atomicity of such updates to atomic variables is not always a problem.
  24. : > For instance, in most cases a signal handler can increment an atomic
  25. : > counter (e.g. a timer) without difficulties, even though the
  26. : > read/modify/write sequence is not atomic.  In the case of nonatomic
  27. : > variables, atomicity must be enforced by blocking certain signals.
  28. : > Such blockage could be portably implemented via atomic blockage flags,
  29. : > which, in turn, are volatile atomic variables that must be read by
  30. : > signal handers.
  31. : Although that could keep them from reading a bad value,
  32. : they have no way to wait for it to become valid if they
  33. : interrupted the owner. So, the updater thread would have
  34. : to fully block the signals that really need the value in the
  35. : handler for handling to proceed.  That is, the problems
  36. : are more severe than between threads that do not interrupt
  37. : each other (a signal handler is just a specialized thread,
  38. : whether or not the environment's terminology calls it that
  39. : is irrelevant).
  40.  
  41. Agreed: the need to block concurrent access to shared data is often
  42. inevitable.  To lock out standard threads during such a critical
  43. section, one acquires a lock.  To lock out signal-sustained
  44. pseudothreads, one blocks the corresponding signals.  It is a defining
  45. characteristic of threads, however, that they can wait.
  46.  
  47. Tom Payne
  48.  
  49. [Moderator's note: this is a valuable discussion, but it's beginning to
  50. drift away from C++ standardization.  I suggest continuing it in
  51. comp.compilers.  mha]
  52.  
  53. ---
  54. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  55.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  56.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  57.